home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / protocol / standard / ccitt / 1992 / x / x411.asc < prev    next >
Text File  |  1993-07-14  |  15KB  |  333 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.                                   - 2 -
  17.                               AP IX-56-E 
  18. If  an  originator-requested-alternate-recipient  has   been   specified   by   the
  19. originator  of  the  message,   the   message   shall   be   redirected   to   that
  20. alternate recipient in preference to one assigned by the recipients-MD.
  21.  
  22.  
  23.  
  24.                                   - 3 -
  25.                               AP IX-56-E 
  26.  
  27. videotex,     ia5-text-to-telex,     telex-to-g3-facsimile,      ia5-text-to-g3-facsimile,
  28. ia5-text-to-g4-class-1,    ia5-text-to-videotex,     teletex-to-ia5-text,     teletext-to-
  29. g3-facsimile,     teletex-to-g4-class-1,      teletex-to-videotex,      videotex-to-telex,
  30. videotex-to-ia5-text, or  videotex-to-teletex.  Other  types  of  explicit-conversion  may
  31. be  defined  by  future  versions  of  this  Recommendation.  Explicit-conversion    shall
  32. be performed as specified in Recommendation X.408.
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.                                   - 4 -
  42.                               AP IX-56-E 
  43. facsimile-delivery,     ia5-terminal-delivery,     videotex-delivery     or      telephone
  44. delivery.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51. cannot   be    found,    a    recipient-improperly-specified-abstract-error    shall    be
  52. returned to the originator of the message.
  53.  
  54. In  the  absence  of   this   argument,   the   default   physical-forwarding-address-not-
  55. requested shall be assumed.
  56.  
  57.  
  58. originator  of   the   message.   The   content-type   shall   be   either   built-in   or
  59. extended.
  60.  
  61. A built-in content-type may have one of the following values:
  62.  
  63.  
  64. external: denotes a content-type which is reserved for use when
  65. interworking between 1988 systems and 1984 systems (see
  66. Recommendation X.419);
  67.  
  68. One specific value of an extended content-type which has been
  69. defined by this Recommendation is inner-envelope: an extended
  70. content-type that is itself a message (envelope and content),
  71. for forwarding by the recipient named on the outer-envelope to
  72. those named on the inner-envelope (Note that the inner-envelope
  73. and content may be protected by securing the content of the
  74. outer-envelope using the security arguments (see
  75. clauses 8.2.1.1.1.25 to 8.2.1.1.1.32).
  76.  
  77. Success of  a  probe  does  not  guarantee  that  a  subsequently  submitted  message  can
  78. actually be delivered  but  rather  that,  currently,  the  recipient  is  valid  and  the
  79. message would encounter no major obstacles to delivery.
  80.  
  81.  
  82. determines  whether  expansion  of  the  specified  DL  (but  not  of  any   nested   DLs)
  83. would occur.
  84.  
  85. message has been redirected and the time at which the redirection was
  86. performed.  It may be generated by the MTS. A different value of this
  87. argument may be present for each occasion the message was redirected.
  88. appended to the list of intended-recipient-names.
  89.  
  90. The intended-recipient-name contains the OR-name of an individual or
  91. DL intended-recipient and the time at which the message was redirected
  92. to an alternate recipient.
  93.  
  94. add recipients to the copy of the message delivered to the recipient
  95. and the time of each expansion. It shall be generated by the MTS if
  96. any DL-expansion has occured.
  97.  
  98. This  argument  contains   a   sequence   of   OR-names   and   associated   times   which
  99. document the history of the origin of the subject-message. The first 
  100. OR-name in the sequence is the OR-name of the originator of the subject,
  101. and the remainder of the sequence is a sequence of OR-names of the DLs
  102. that have been expanded in directing the subject towards the recipient
  103. (the latter being the same as the DL-expansion-history). It shall be
  104. generated by the originating-MTA of the report if any DL-expansion has
  105. occured on the subject.
  106.  
  107. The originator-and-DL-expansion-history contains the OR-name of the
  108.  
  109.  
  110.  
  111.                                   - 5 -
  112.                               AP IX-56-E 
  113. originator of the subject and each DL and the time at which the
  114. associated event occured.
  115.  
  116.  
  117. the security-policy in force; unable-to-downgrade: the subject could not
  118. be transferred because it could not be downgraded (see Annex B to
  119. Recommendation X.419).
  120.  
  121.  
  122. information-type.     Deliverable-encoded-information-types     also     indicates     the
  123. possible encoded-information-types to which implicit conversion can be performed.
  124.  
  125.  
  126. abstract-operation, and are defined in clause 8.3.1.3.1. Except for
  127. permissible-security-context, they may be generated by the MTS-user.
  128.  
  129. recipient-name: the OR-Address and OR-Directory-name of the
  130. intended-recipient of the token;
  131.  
  132. defined for a function marked as critical-for-delivery, or shall not deliver
  133. the  message  or  probe  and  shall   return   a   non-delivery-report   with   the   non-
  134. delivery-diagnostic-code set  to  unsupported-critical-function.  A  recipient  MTS-  user
  135. shall correctly perform the procedures defined for a function marked as critical-for-delivery or shall return an Unsupported-critical-function
  136.  
  137. If  the  MTA  or  MTS-user  cannot  correctly  perform  the  procedures  defined   for   a
  138. function marked "critical-for-delivery" in a report, then the report is discarded.
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.                                   - 6 -
  149.                               AP IX-56-E 
  150.  
  151. -- Upper Bounds
  152.  
  153. ub-bit-options,      ub-built-in-content-type,      ub-built-in-encoded-information-types,
  154. ub-common-name-length, ub-content-id-length, ub-content-length,
  155. ub-content-types,      ub-country-name-alpha-length,       ub-country-name-numeric-length,
  156. ub-dl-expansions, ub-domain-defined-attribute-value-length,
  157. ub-domain-defined-attributes, ub-domain-defined-attribute-type-length,
  158. ub-domain-name, ub-e163-4-number-length, ub-e163-4-subaddress-length,
  159. ub-encoded-information-types, ub-extension-attributes, ub-extension-types,
  160. ub-generation-qualifier, ub-given-name-length, ub-initials-length,
  161. ub-integer-options, ub-labels-and-redirections, ub-local-id-length,
  162. ub-mta-name-length, ub-mts-user-types, ub-numeric-user-id-length,
  163. ub-organization-name-length, ub-organization-unit-name-length,
  164. ub-organizational-units, ub-password-length, ub-pds-name-length,
  165. ub-pds-parameter-length, ub-postal-code-length, ub-privacy-mark-length,
  166. ub-queue-size, ub-reason-codes, ub-recipients,
  167. ub-recipient-number-for-advice-length,       ub-redirections,       ub-security-categories
  168. ub-security-labels, ub-security-problems, ub-supplementary-info-length,
  169. ub-surname-length, ub-terminal-id-length, ub-tsap-id-length, ub-transfer,
  170. ub-informated-address-length, ub-x121-address-length
  171.  
  172.  
  173. Otherwise  depending  on  bilateral  agreement  or   intra-domain   policy   the   current
  174. time is noted as the message arrival  time  and  the  message  is  held  until  expiration
  175. of  the  deferred-delivery-time.  The  message  and  timestamp  are   then   returned   as
  176. result. The procedure then terminates.
  177.  
  178.  
  179. domain  is  added  with  relay  as  action.   If   an   arrival   time   accompanies   the
  180. message, then delivery deferral has occured and deferred-time is set to the  current  time
  181. and  arrival-time  is  set   to   the   accompanying   timestamp   value.   Otherwise   no
  182. deferral has occured and the arrival-time is set to the current time.
  183.  
  184.  
  185. 3)  If  any  of  the  extension  fields  is  marked  critial  for  relaying  but  is   not
  186. semantically  understood  by  the  MTA,  the  procedure  returns   a   report   generation
  187. instruction. The non-delivery-reason-code is set to transfer-failure and the   non-delivery-diagnostic-code to unsupported-critical-function. The procedure then 
  188. terminates.
  189.   
  190.  
  191. Note  -  This  procedure  may  be  called  multiple  times  for  any  particular  message.
  192. In  such  cases,  the  procedure  ignores  per   recipient   instructions   generated   by
  193. previous calls to this procedure which have not yet been acted upon elsewhere.
  194.  
  195. If  the  per  recipient  instruction  indicates  a  delivery  failure,  then   the   value
  196. for  Originator-requested-alternate-recipient   is   examined   for   possible   recipient
  197. substitution. If an alternate recipient is  determined  and  no  security  parameters  are
  198. violated,   then   a   redirection   instruction   is   generated   and   the    procedure
  199. terminates.
  200.  
  201. Otherwise   the   procedure   returns   a   report   generation   instruction   for   this
  202. recipient.  The  non-delivery-reason-code  and  non-delivery-diagnostic-code   are   those
  203. supplied  by  the  Message-delivery  or  Report-delivery  procedure.  The  procedure  then
  204. terminates.
  205.  
  206. recipient.   If   not,   the   value   for   Originator-requested-alternate-recipient   is
  207. examined  for  possible   recipient   substitution.   If   this   reveals   no   alternate
  208. recipient, the the value for alternate-recipient-allowed and any  MD  specified  alternate
  209. recipient are considered.  If  an  alternate  recipient  is  determined  and  no  security
  210. parameters  are  violated,  then  a  redirection  instruction   is   generated   and   the
  211. procedure terminates.
  212.  
  213. Otherwise   the   procedure   returns   a   report   generation   instruction   for   this
  214. recipient.
  215.  
  216.  
  217.  
  218.                                   - 7 -
  219.                               AP IX-56-E 
  220.  
  221. assigned-              reassignment-
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.                                   - 8 -
  231.                               AP IX-56-E 
  232.  
  233. using  the  recipient-name  from  argument  2   to   form   the   intended-recipient-name,
  234. obtaining the redirection-reason  from  argument  4  and  containing  the  Time  at  which
  235. this redirection is performed.  The  OR-name  supplied  in  the  first  argument  is  then
  236. substituted for that recipient-name.
  237.  
  238. 3)       In  the  other-actions   field   the   current   trace-information,   the   value
  239. redirected is set to true.
  240.  
  241. 4)      The message transfer envelope is updated as follows:
  242.  
  243.         recipient-name:                           replaced
  244.          trace-information:                        indicate redirected
  245.          redirection-history:                      append previous
  246.                                                    recipient-name and
  247.                                                    redirection-reason
  248.          originator-requested-alternate-recipient:   deleted   if,   and   only   if   the
  249.                                                    redirection-reason            indicates
  250.                                                    originator-requested- 
  251.                                                    alternate-recipient.
  252.  
  253. 8)     If the new report  request  values  (determined  in  step  5)  or  the  DL's  local
  254. policy  will  prevent  the  originator  from  receiving  a   requested   delivery   report
  255. from the DL's  members,  then  a  copy  of  the  message,  with  delivery  report  request
  256. instructions for the expanded DL, is constructed and returned along with the message.
  257.  
  258. 9)     The  procedure  returns  the  revised  message  and  the  optional  report  request
  259. and then terminates.
  260.  
  261. for which 0 < j  </=p  the  associated  trace  info  element  is  [MD(j)  relayed,  op(j)]
  262. and op(j) = nil.  That  is,  a  loop  is  detected  if  M  arrives  at  an  MD  which  has
  263. already relayed it and each MD afterwards has  also  relayed  it  without  performing  any
  264. operation other  than  routing.  If  a  loop  is  detected,  then  the  algorithm  returns
  265. an error indicating the problem, and terminates.
  266.   
  267. If  the  report  is  not  to  be  suppressed,  the   MTA   then   replaces   the   OR-name
  268. currently in the report-destination-name field by the OR-name immediately  preceding  that
  269. one  in  the  originator-and-DL-expansion-history  field.  Thus   the   report   acquires,
  270. as  a  new  destination,  the  next  entry  back  along  the  chain  of  entries  in   the
  271. originator-and-DL-expansion-history field:
  272.   
  273.  
  274. 4)     If authentication is not required Messages-waiting is returned if the MTS-user subscribes to the Hold for Delivery element-of-service, and the procedure 
  275. terminates.
  276.  
  277. In  the  case  of  recipient-name  the  MTA  may  use  the  requested-delivery-method,  if
  278. present,  as  an  indication  of  which  form  of  OR-address  the  directory-name  should
  279. be mapped  to.  If  a  form  of  OR-address  appropriate  to  the  request-delivery-method
  280. cannot  be  found,  the  recipient-improperly-specified  abstract-error  is  returned   by
  281. the MTA.
  282.  
  283. c)     If  a  recipient-name  contains  an  OR-address  of  a  form  not  appropriate   to
  284. the   requested-delivery-method,   if    present,    the    recipient-improperly-specified
  285. abstract-error is returned by the MTA.
  286.  
  287.  
  288. 1)      An  empty  or,  if  requested,  a  proof-of-delivery   and   optional   recipient-
  289. certificate  result  passed  back  from  the  MTS-user  as  an  indication  of  successful
  290. delivery with no reporting requirements.
  291.  
  292. 2)      If  a  report  is  required,  the  main  module  is   invoked   and   passed   the
  293. message with per-recipient  instructions  describing  any  delivery  problems  encountered
  294. and/or indicating successful deliveries to be reported on.
  295.  
  296. unable-to-transfer and unsupported-critical-function respectively.
  297.  
  298.  
  299.  
  300.                                   - 9 -
  301.                               AP IX-56-E 
  302.  
  303. then, subject to  the  security  policy,  a  report  instruction  for  this  recipient  is
  304. generated.   The   values   of   non-delivery-reason-code   and   non-delivery-diagnostic-
  305. code are unable-to-transfer and secure-messaging-error respectively.
  306.  
  307. 6)      If  delivery  is  barred  by  restrictions  imposed  in   a   previously   invoked
  308. Register  or  Delivery-control  abstract-operation,  then,  subject   to   the   security-
  309. policy in force, the MAT will hold the message  pending  the  lifting  of  the  applicable
  310. restriction(s).
  311.  
  312. 8)      If  restricted  delivery  is  enforced,   and   the   recipient   falls   in   the
  313. category of unauthorized  senders,  then  a  report  instruction  is  generated  for  this
  314. recipient.  The  value  of  non-delivery-reason-code  is  set  to  restricted-   delivery.
  315. Processing then terminates for this recipient.
  316.  
  317.  
  318. unable-to-transfer and unsupported-critical-function respectively.
  319.  
  320.  
  321. security-policy, then the report is discarded.
  322.  
  323. 2)       If  Report  delivery  is  barred  by  restrictions  imposed   in   a   previously
  324. invoked  Register  or  Delivery-control   abstract-operation,   then,   subject   to   the
  325. security-policy in force, the MAT  will  hold  the  report  pending  the  lifting  of  the
  326. applicable restriction(s). Restrictions are established by arguments of the Delivery-control or Register abstract-operation as described in
  327. clause 8.3.1.3.1.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.